Principe solide¶

C'est quoi SOLID¶

En programmation orientée objet, SOLID est un acronyme mnémonique qui regroupe cinq principes de conception destinés à produire des architectures logicielles plus compréhensibles, flexibles et maintenables. Les principes sont un sous-ensemble de nombreux principes promus par l'ingénieur logiciel et instructeur américain Robert C. Martin.

-- wikipedia

  • C'est un accronyme qui représente 5 conceptes

  • Très axé sur la programmation objet

  • C'est un moyen de savoir si du code est bon

Mais, ça veut dire quoi?¶

  • Responsabilité unique (Single responsibility principle)

  • Ouvert/fermé (Open/closed principle)

  • Substitution de Liskov (Liskov substitution principle)

  • Ségrégation des interfaces (Interface segregation principle)

  • Inversion des dépendances (Dependency inversion principle)

Responsabilité unique¶

une classe ne doit changer que pour une seule raison

There should never be more than one reason for a class to change."[5] In other words, every class should have only one responsibility.

-- Robert C. Martin (Uncle bob)

Conséquences¶

  • Une class doit être petite

  • Un objet doit être immutable sauf, au maximum à une seule place

Regardons ce mauvais exemple...¶

Ouvert/fermé¶

Principe Ouvert/fermé¶

une entité applicative (classe, fonction, module ...) doit être fermée à la modification directe mais ouverte à l'extension

Software entities ... should be open for extension, but closed for modification.

-- Robert C. Martin (Uncle bob)

Conséquence¶

  1. Le plus qu'une classe est utilisé, le plus difficile c'est d'en hériter

  2. Il ne faut jamais changer les arguments d'une méthode hérité

  3. Il faudrait toujours appeler la méthode parente

  4. Une classe qui a des enfants ne peut changer façilement

Regardons ce mauvais exemple...¶

Principe de substitution de Liskov¶

Substitution de Liskov¶

une instance de type T doit pouvoir être remplacée par une instance de type G, tel que G sous-type de T, sans que cela ne modifie la cohérence du programme

Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it

-- Robert C. Martin (Uncle bob)

En français¶

Une sous-classe doit être capable d'être utilisé aux même places que la classe parente

Conséquences¶

  1. Le plus qu'une classe est utilisé, le plus difficile c'est d'en hériter

  2. Le plus qu'une classe à d'enfants, le plus difficile il est de changer la classe

Ségrégation des interfaces¶

préférer plusieurs interfaces spécifiques pour chaque client plutôt qu'une seule interface générale

Clients should not be forced to depend upon interfaces that they do not use.

-- Robert C. Martin (Uncle bob)

Go proverbs¶

interface{} says nothing.

The bigger the interface, the weaker the abstraction.

-- rob pike

https://go-proverbs.github.io/

Rich Hickey¶

https://www.youtube.com/watch?v=aSEQfqNYNAc

La banane¶

I think the lack of reusability comes in object-oriented languages, not functional languages. Because the problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.

-- Joe Armstrong

Conséquence¶

  • Une interface devrait être le plus petit possible

  • En python, les

Inversion des dépendances¶

il faut dépendre des abstractions, pas des implémentations

-- Robert C. Martin (Uncle bob)

Principe d'inversion des dépendances¶

Les deux assertions de ce principe sont :

  1. Les modules de haut niveau ne doivent pas dépendre des modules de bas niveau. Les deux doivent dépendre d'abstractions.

  2. Les abstractions ne doivent pas dépendre des détails. Les détails doivent dépendre des abstractions.

Les modules de haut niveau ne doivent pas dépendre des modules de bas niveau. Les deux doivent dépendre d'abstractions.¶

Analogie¶

  • Ma balayeuse ne dépend pas de l'"électricité", elle dépend de la prise électrique.

    • balayeuse: haut niveau
    • électricité: bas nieveau
    • prise électrique: interface

Dépendence directe¶


flowchart TD
    T[Base de donne] --> P1[Load User]

Dépendence avec interface directe¶

flowchart TD
    T[Base de donne]-- implemente -->I[User Repository Interface] 
    P1[Load User]-- utilise -->I

Pour les testes..¶

  1. Ajoutons une implementation "in memory"
flowchart TD
    T[Base de donne]-- implemente -->I[User Repository Interface] 
    F[In memory db]-- implemente -->I
    P1[Load User]-- utilise -->I

La production peut utiliser la base de donnée¶

flowchart TD
    Controller --> P[+]
    T[Base de donne] --> P
    P1[Load User] --> P

Les testes peuvent utiliser la base de donnée "in memory"¶

flowchart TD
    Test --> P[+]
    T[In memory db] --> P
    P1[Load User] --> P